Commonly, pluralities of computers, databases, printers and other computing or computing related devices are often established in clusters or as members or elements of a network, hereafter, collectively “Clusters”. Clusters are often defined as a parallel or distributed system that consists of a collection of interconnected whole computers, that is utilized as a single, unified computing resource. As such, it is commonly appreciated that Clusters commonly consist of computing devices (i.e., nodes) and other peripheral devices to which access thereto may be controlled by particular nodes. Clusters enable information system managers to share a computing load over several systems, thereby enhancing the capabilities of the system as a whole, minimizing the adverse effects of failures of certain nodes or devices on a Cluster, and allowing for the expansion of capacity and capabilities of a given Cluster by adding additional or different nodes and/or devices to the Cluster.
As Clusters have increased in size and complexity, interest has arisen in processes for managing the utilization of resources associated with a Cluster (for example, printers, processors, data storage devices, data files, displays and other virtual and real resources). Throughout this description a device, whether real or virtual, accessible or utilized by a Cluster shall be referred to hereinafter as a “Resource”. Similarly, a computing device (for example, a processor, server, mainframe computer or similar device) utilized in the utilization of itself or other Resources, which may be directly or indirectly connected to or accessed by such a computing device, shall be referred to hereinafter as a “Node”. Those skilled in the art appreciate that Resources and Nodes can include practically any electronic device and be configured in any configuration desired.
Additionally, many large Clusters, in addition to managing access to Resources, have to ensure that sufficient Resources are highly available (i.e., the Resources are guaranteed to have a minimum operating reliability often measured in the 99.999% and better ranges). As such, efficient and effective processes for managing the utilization of Resources are highly desirable.
Currently, one method for managing Resources on a Cluster utilizes databases that are maintained by every Node on the Cluster. These databases keep track of which Resources are being utilized at any particular time by any client throughout the Cluster. As is commonly appreciated, a client may be another Resource on a Cluster, a device external to the Cluster (for example, a web browser on a user's personal computer (i.e., a Node) connected to an Internet based Cluster), or anything else that requires access to a Resource associated with a Cluster. Those persons, Resources, Nodes, Clusters and/or any other entity that desires to utilize a Resource on a Cluster are hereinafter collectively referred to as a “Client”.
Since Clusters can often be quite large with numerous Resources being utilized by widely dispersed Clients, keeping such databases up to date is often an inefficient and inaccurate process. For example, in order to determine whether a Resource is currently being utilized and then to reserve a Resource, the multi-node database approach often requires a Node to keep track of every lock maintained on the Cluster. When a Client desires to lock-up a Resource, the Client's Node then has to determine whether any other Node has a lock on the Resource via its look-up tables. Further, when a lock is released, the Node then has to notify every other Node on the Cluster of the releasing of the lock. At which instance, every Node on the Cluster must update their respective lock tables. As such, this approach can be very time intensive for all the Nodes on a Cluster. Thus, a better process is needed.
Another process commonly utilized to reserve and/or “lock-up” a Resource is to utilize a proxy maintained by a proxy server identified for the Resource. This approach eliminates the need for each Node on the Cluster to maintain up-to-date databases or listings identifying the utilization of every Resource on the Cluster. Instead, a single Node provides the beforementioned proxy services. Usually, but not always, this Node is the Node by which the specific Resources are accessed and/or controlled. However, this approach is often undesirable because control of the Resource is often maintained by a single Node. If the Node controlling a Resource fails, for whatever reason, often the jobs to be processed by the Resource (which commonly are located on a proxy queue in a local memory device associated with the Node) are lost and are not recoverable. As such an efficient and reliable process for determining whether a Resource on a Cluster is available and “locking-up” the Resource, when available, is needed.